Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow builtins in yul identifier paths in antlr grammar. #12545

Merged
merged 2 commits into from
Jan 17, 2022

Conversation

ekpyron
Copy link
Member

@ekpyron ekpyron commented Jan 17, 2022

Came up in #12470

@@ -564,7 +564,7 @@ yulFunctionDefinition:
* While only identifiers without dots can be declared within inline assembly,
* paths containing dots can refer to declarations outside the inline assembly block.
*/
yulPath: YulIdentifier (YulPeriod YulIdentifier)*;
yulPath: YulIdentifier (YulPeriod (YulIdentifier | YulEVMBuiltin))*;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strictly speaking probably address.test would in theory be a valid yulPath as well, but I'd say this hack is good enough for all intents and purposes.

@ekpyron ekpyron changed the title Allow builtins as yul identifier paths in antlr grammar. Allow builtins in yul identifier paths in antlr grammar. Jan 17, 2022
@ekpyron
Copy link
Member Author

ekpyron commented Jan 17, 2022

If we want, we can think about whether we can do this "properly", i.e. have the solidity yul version just parse identifiers containing dots - but since this won't really happen too much in practice, since we reserved identifiers with dots for high-level-language specific constructions and we're unlikely to do more weird stuff like with functionPointer.address, I'd say we should at least temporarily merge this, s.t. we can proceed with #12470.

cameel
cameel previously approved these changes Jan 17, 2022
Copy link
Member

@cameel cameel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one cosmetic tweak needed so I'm approving already.

By the way. How does this affect recent efforts to specify Yul formally? Was that in any way dependent on our grammar definitions or done from scratch?

…tion_pointer.sol

Co-authored-by: Kamil Śliwak <kamil.sliwak@codepoets.it>
@ekpyron
Copy link
Member Author

ekpyron commented Jan 17, 2022

By the way. How does this affect recent efforts to specify Yul formally? Was that in any way dependent on our grammar definitions or done from scratch?

I wouldn't be aware of the grammar being used for that (or actually for anything apart from our docs and tests for that matter).

@ekpyron ekpyron merged commit 79e9d61 into develop Jan 17, 2022
@ekpyron ekpyron deleted the yulGrammarFluke branch January 17, 2022 19:42
@cameel
Copy link
Member

cameel commented Jan 17, 2022

@ekpyron
Copy link
Member Author

ekpyron commented Jan 17, 2022

Ah, that one you meant - that's a rather bold simplification of Yul anyways :-).

@cameel cameel mentioned this pull request Jan 18, 2022
github-merge-queue bot pushed a commit to NomicFoundation/slang that referenced this pull request Apr 25, 2024
Found with the Sanctuary run on Arbitrum:
https://github.com/NomicFoundation/slang/actions/runs/8803528884
This fixes the last bug in Arbitrum data set:
https://github.com/Xanewok/slang/actions/runs/8813993801

Implemented in ethereum/solidity#12016 (0.8.10),
grammar updated in ethereum/solidity#12545.

This matches the upstream grammar, however:
- this is more relaxed and parses code that would be rejected by
validation, i.e. `<built-in> := ...`
- we do get a bit of noise, since most of the paths will never contain
the built-in.

I've also changed `YulidentifierPath` to `YulPath` to match upstream and
since it's not only an identifier anymore.

This also includes a patch level bump - while technically it's breaking
the CST shape, I'd consider this a (hopefully last?) grammar bug fix
that might justify the patch level.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants